Thanks. In general it seems find to me. I have a few comments.

It seems a little "picky" to me to require users to specify "axis" if the carriage name is "x", "y", or "z". I'd expect most users would use these basic names for the main carriages. Thus the deprecation warnings seem a little pedantic. YMMV.

If we're updating the example configs to use longer names, I think names something like "my_x_carriage" or "my_second_extruder_carriage" would be easier to understand (instead of, for example, "xc").

In all of the above, though, I'll defer to your judgement. So, let me know when you are ready to commit and I will.

Cheers,
-Kevin

Thanks Kevin,

It seems a little "picky" to me to require users to specify "axis" if the carriage name is "x", "y", or "z". I'd expect most users would use these basic names for the main carriages. Thus the deprecation warnings seem a little pedantic. YMMV.

Well, if we want people to use longer, more descriptive names for the carriages, then it could make sense to promote the ideal configuration while the adoption of generic_cartesian kinematics is low (so that fewer users would be affected), before we start deprecating hybrid_corex? and dual_carriage outside of generic_cartesian, and it also makes documentation a bit simpler. Another reason for that is the work to let the users map carriages to extra axes. I do think there's no reason to forbid the following sequence of commands

SET_DUAL_CARRIAGE CARRIAGE=u_carriage MODE=PRIMARY
SET_DUAL_CARRIAGE CARRIAGE=x_carriage MODE=DIRECT GCODE_AXIS=U

but the counterpart

SET_DUAL_CARRIAGE CARRIAGE=u MODE=PRIMARY
SET_DUAL_CARRIAGE CARRIAGE=x MODE=DIRECT GCODE_AXIS=U

(the second command) would look a bit out of place.

However, I do get another train of thought that [carriage x] and alike are nice and simple shortcuts. So I could be swayed either way, TBH.

If we're updating the example configs to use longer names, I think names something like "my_x_carriage" or "my_second_extruder_carriage" would be easier to understand (instead of, for example, "xc").

Thanks, I will consider that. My biggest dislike here is the kinematics description part of steppers, like

[stepper my_stepper_x]
carriages: my_x_carriage+my_second_extruder_carriage

like, the names of carriages distract a bit from the actual kinematics part, but it is not too bad.

I think those are all good points.

My biggest dislike here is the kinematics description part of steppers, like
[stepper my_stepper_x]
carriages: my_x_carriage+my_second_extruder_carriage

True. Maybe there is a middle ground though (somewhere between very verbose and very terse).

Cheers,
-Kevin

OK, so I updated the documentation and examples to have a bit more descriptive carriage names. As for the axis option, my proposal is the following.

I separated all the deprecation into a separate commit 230f7e5, and I suggest that we go with deprecating the automatic axis inference right now, since it does simplify documentation and code. For now this is just a warning and existing configuration will not be broken. However, if we receive complains and/or alternative suggestions on discord or discourse, we can have a discussion there, and we can ultimately decide to revert just that commit, I would not mind it then.

Okay, thanks. I'll commit when you are ready.

Cheers,
-Kevin

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.